Security-JAWS 第29回レポート #secjaws #secjaws29 #jawsug

Security-JAWS 第29回のレポートです。楽しい内容てんこ盛りでした！

#JAWS-UG

#セキュリティ

#レポート

#AWS

臼田佳祐

2023.05.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

Security JAWS 第29回が開催されましたのでレポート致します。

Security-JAWS【第29回】勉強会 2023年05月25日(木) - Security-JAWS | Doorkeeper

動画

レポート

Session1:AWS Summit Tokyo 2023オンデマンド配信を楽しむためのセキュリティ関連トピックご紹介アマゾンウェブサービスジャパン合同会社セキュリティソリューションアーキテクト勝原達也さん

AWS Summit Tokyo 2023で実施されたセッションのオンデマンド配信が始まりました
Summitのテーマは「見て、触れて、楽しむ学びの場」
現地ならではのハードウェア展示があった
- AWSのNitroに関するハードウェアもあった
リーダーシップのセッションでもセキュリティについて触れられていた
- 300を超えるセキュリティサービスと機能がある
- 高いセキュリティやコンプライアンスを求めている企業がAWSを選択する理由として、セキュリティが挙げられている
本当はすべてのセッションを見ていただきたいが、大変なので皆さんのかわりに一通り見ておきました
- ほぼすべてのセッションでセキュリティに言及があった
- 一部のみピックアップして紹介する
- 編集注: セッション数が多いので、セッション番号のみ記載しているのもありますが後ほどタイトルを補完します
AWSのセッション
- ストレージ視点でのセキュリティ
  - AWS-02: 性能、コスト、保護すべてがかなう AWSストレージサービス
- ネットワークアーキテクチャとセキュリティ
  - AWS-03: AWSネットワーク管理をステップアップしたい方に送る、次の一手
  - AWS-42:
    - 比較的ネットワークにディープダイブしたセッション
- 運用からセキュリティを考える
  - AWS-04: インシデントを起点に考える、システム運用のユースケースのご紹介
    - 日本のセキュリティは予防にフォーカスが当たりがちだが、このセッションは運用が回るセキュリティのヒントになる
    - イチオシのセッション
- 可用性はセキュリティの重要要素 - レジリエンス
  - AWS-14: Resilience at AWS 回復力のあるシステムを作る為の設計指針
  - AWS-43: ミッションクリティカルシステムをAWSに載せるには？
  - AWS-49:
    - 可用性もセキュリティの大事な要素
    - なにか起きてもすぐに復旧できる事が大事
- データ活用 - DWHに関するセキュリティ
  - AWS-35: AWSでミッションクリティカルなデータウェアハウスを構築する方法
    - DWHでもミッションクリティカルなセキュリティが求められる様になってきている
- AWSにおける「ゼロトラスト」の考え方
  - AWS-39: AWSでゼロトラストを実現するためのアプローチ
    - どのように考えてやっていくかというセッション
- 権限管理のグランドデザインと優れたガードレール
  - AWS-40 デジタルトランスフォーメーション(DX)の成功を支える権限管理
    - ちょっと不思議なタイトル
- AWS Marketplaceに関するセキュリティ
  - AWS-44: [ISVやSaaS事業向け] AWSで自社ソフトウェアやサービスを販売しよう！
    - セラーとバイヤー双方の保護についての解説
- 仮想デスクトップによるセキュリティ確保のヒント
  - AWS-47: 仮想デスクトップ環境の運用を見直そう！新た場仮想デスクトップサービスの選択肢とAmazon AppStream 2.0
- 政府・自治体におけるクラウド利用とセキュリティ
  - AWS-50
  - AWS-51
  - AWS-52
  - AWS-53
お客様セッション
- AWSを活用した全社共通クラウド基盤
  - CUS-02: 中外制約様
  - CUS-05: 三菱マテリアル様
- セキュアなリモートメンテナンス構成事例
  - CUS-11
- デジタル庁
  - CUS-16
  - 現行踏襲を望む人が多いところ、意思決定する勇気が必要
- 金融機関
  - CUS-31: 三菱UFJ銀行様
  - 素早くAI基盤を活用する開発基盤を内製
- 大規模オンプレ活用から大規模AWS活用へ
  - CUS-36: ドワンゴ様
  - テーマは「地方分権とガバナンス」
  - アカウント戦略としてAWS Control Towerを利用している事例
- AWSセキュリティサービスとマネージドサービス活用のねらい・効果
  - CUS-46: パナソニック様
    - 差別化に繋がらない実行基盤は省力化
  - CUS-49 弥生様
    - AWSがセキュリティの面倒をみる部分を増やす
    - 運用チームの作業量を減らすことができた
- SaaSビジネスのセキュリティ / Marketplace活用
  - CUS-48: Works Human Intelligence様
    - 第三者認証の取得について
  - CUS-52: サイバーセキュリティクラウド様
- サービス成長フェーズこそ継続的な改善が大切
  - CUS-51: セーフィー様
    - 長期的に見て改善していく
パートナーセッション
- AP-02
- AP-03
- AP-07
- AP-09
- AP-10
- AP-11
- パートナーとエンドユーザー共同のセッションもある
- 気になるものがあれば見てね
オンデマンド配信は6/23まで

感想

セキュリティ、をテーマにすると対象のセッションはたくさんありますね。私の個人的なオススメはドワンゴさんのセッションです。ぜひ見てみてください！

Session2:AWS WAFおよびWafCharmを複数サービスに導入した結果と課題 ENECHANGE株式会社・CTO室インフラエンジニア兼SRE 岩本隆史さん

プロダクトから独立した部署でセキュリティを見ている
前職ではAWSでサポートをしていた
WafCharmとは
- クラウドWAFの運用を自動化
- AWSだけでなく、Azure / GCPも
どんなことをしてくれるか
- 最適なルールを自動で適用してくれる
- たくさんのルールがあり、ブラックリストの適用などもやってくれる
  - 自分たちでブラックリストの運用をしなくてもいい
- 他にも例えばSQLインジェクションに対応したシグネチャとか
- 自分たちでルールを作って、どれをどうやるか考えなくてもいいので便利
検知状況をメールで通知可能
- メール経由でSlackに通知して利用している
サードパーティのツールだが、AWSが認定している
- AWS認定ソフトウェアであるので安心感がある
導入経緯
- 利用中のWAFで不具合が頻発した
  - エンドユーザーがアクセスしたときにWAFで止まっていた
  - 外部のWAFのネットワーク障害で止まっていた
  - 信頼性の要件的に、移行を検討した
- ほとんどのプロダクトがAWS環境で動いていたのでAWS WAFへの移行を検討した
  - AWSサービスとの相性もいい
  - バックボーンに対する信頼性も高い
- 自分たちで運用するのは大変だなーと思っていたらWafCharmを発見した
- まず3件のプロダクトに導入した
  - スモールスタートした
導入した結果
- WAF運用の第一候補になった
  - 新規のプロダクトを開始するときにまずAWS WAFとWafCharmを第一候補にあがるようになった
  - それだけ信頼されたと思う
- 7件のプロダクトに拡大
  - 他のプロダクトオーナーからもリクエストが来るようになった
- 不具合や誤検知は未報告
  - 今のところない
- 様々なニーズが顕在化
  - プロダクトごとにこういった設定をしたいと要望が上がってくるようになった
  - 「シグネチャは検知のみにしたい」「IPアドレスのブラックリストは検知にしたい」など
課題(要望)
- Terraformで構築不可
  - WafCharmはダッシュボードから設定をしている
  - TerraformのWafCharmプロバイダーがほしい
- 「N回検知したらban」が不可
  - 同じIPから複数回来たら止めたい
- 月次レポートがダウンロード不可
  - ブラウザで表示できるが直接ダウンロードできない
- 通知機能のテストが煩雑
  - テストしようと思うとテスト用のルールを作ってマッチさせて通知をしている
まとめ
- 課題はあるが利用拡大中
- 便利に使っている

感想

WAFのルールを管理するのはなかなか大変なので、それをおまかせできるのはすごく楽でいいですよね。是非活用してみましょう。

Session3:CSPMにおけるトリアージ方法のご紹介 Cloudbase株式会社 CTO 宮川竜太朗さん

普段はCTOとしてCloudbaseのプロダクト責任者をしている
CSPMや各種ベンチマークについて
- CSPMとは
  - クラウドの構成ミスを検知するツール
  - AWSではAWS Security Hub + AWS Configが該当
  - 検知項目の例
    - SSHのポートが開放されているSecurity Groupがある
    - 90日以上利用されていないIAMユーザーがある
- CSPMの基準となるベンチマーク
  - 世界的な基準として策定された守るべきルールセットがある
  - CISやPCI DSS
  - 他にもクラウドベンダーのベストプラクティスもある
CSPMの課題
- CSPMでの危険度と実際の危険度のギャップ
  - ほとんどのチェックが単一のリソースの設定を評価することに起因する
  - SSHのポートが開放されていて本当に危ないケースは、その設定である + それがEC2等にアタッチされている + 到達可能なネットワーク構成になっているという場合
  - この要素のすべてを検知しているわけではない
  - 利用されていないIAMユーザーの場合で本当に危ないIAMユーザーは90日以上利用されていない + 対象のIAMユーザーがMFAが設定されていない + 強い権限を持っている場合
  - もちろん本当に危ないものでなくても多層防御などの観点で対応はすべき
統計で見る危険度のギャップ
- Security Group
  - いくつかの企業に調査して定量的に分析してみた
  - 実際に検知されているSecurity Groupが使われている場合
    - 35%だった、思ったより低い
  - EC2に実際にアタッチされているSSHポートが公開されていて、到達可能であるか
    - 71%が到達可能
    - 残りはプライベートネットワーク内
  - 実際のリスクが低くなる事がわかる
  - 対応の優先度をそれに合わせてコントロールしてもいい
- 利用していないIAMユーザー
  - 対象のユーザーが強い権限を持っている場合
    - 57%
    - 残りの43%は被害が限定的である可能性が高い
  - これに加えてMFAが無効化されている割合
    - 47%
  - 退職者の棚卸しができていないかもしれないので、対応は勿論必要
- リスクの取捨選択の重要性
  - 現実的には見つけたら即座に対応することが重要
  - 手動でやるのは大変なので取捨選択をできる限り自動化すべき
  - こういったリスクの取捨選択・優先度付をトリアージと呼ぶ
トリアージの方法
- 銀の弾丸はない
  - 対応した製品を使う
  - 自前で必要なスクリプトを用意する
- 見るべきコンテキストの例
  - インターネットから到達可能か
  - 強い権限を持っているか
  - 重要なデータがあるか
  - など
    - 開発環境か本番環境かとか
    - どういう基準を使うか社内で議論するのもいい
- トリアージ自動化の具体例
  - CloudQueryというOSSを使うとトリアージを楽にすることが可能
    - メタデータの収集が簡単にできる
    - インターネットからトラフィックが到達可能なEC2インスタンスのクエリの参考例を紹介(詳しくはスライドを見てね)
Cloudbaseでのトリアージ
- リスクに応じて表示
- 対象のリソースに関するマッピングの図があり視覚的にわかりやすい
- 直し方のドキュメントも丁寧に書いてある
まとめ
- CSPMで検出されるリスクを全部対応するのではなく本当に危ないものにトリアージをして対応しましょう

感想

CSPM全般では、実際の環境のコンテキストは見られていないことが多いので、優先順位付けで課題があるのはよくあることですね。もちろんガバナンスとしては上がるものは一通りやっていきましょうですが、コンテキストを読み取ってくれるならおまかせしたいですね。

Session4:Datadogで実現するセキュリティオブザーバビリティ Datadog Japan 合同会社角田高彬さん

Datadogでセールスエンジニアをしている
前職ではインフラを中心にやっていた
話さないこと/話すこと
- 話さないこと
  - よくあるセキュリティ課題の例示
  - セキュリティの概念や理論
  - AWSセキュリティ機能など他との比較
- 話すこと
  - Datadogのセキュリティ機能でできること
  - メリット
Datadogが提供するセキュリティ機能
- Datadogとは
  - 統一されたオブザーバビリティ基盤
    - AWS以外も含めて様々なクラウドやOSミドルなど様々なソース
    - いろんなところで1つの基盤で使える
    - 可観測性がある
- 市場からの評価
  - ガートナーやフォレスターでリーダーに
- 日本、セキュリティ、コンプライアンスへ注力している
  - 国内に閉じてデータ処理とデータ保持が可能
  - Datadog Security Labsでセキュリティに関する記事やOSS公開もしている
- 様々なセキュリティ機能も提供
  - インフラモニタリング
    - クラウドセキュリティ管理
      - CSPM
      - ワークロードセキュリティ
      - リソースカタログ
  - アプリケーションパフォーマンスモニタリング
    - アプリケーションセキュリティ管理
    - アプリケーション脆弱性管理
  - ログ管理
    - SIEM
- 活用イメージ図
  - スライドを見てね
  - エージェントを使ったりクローラーを使ったりして収集できる
Datadogでセキュリティ対応するメリット
- Datadogのいいところ5つ
  - ロゴ
    - bitsくん
    - 可愛いロゴがあると障害対応も頑張れる
  - 使いやすさ
    - クリック操作で機能を横断して情報にアクセス
    - クエリ扶養で情報を絞り込みできる
    - 様々なチームが横断して活用できるツール
    - デモで詳しく見せます
  - 製品開発への投資
    - 収益の30%を投資している
    - R&D投資に関するデータもあるよ
    - 歴史
      - 2018年: オブザーバビリティの3つの柱がリリース
      - 2022年: 4つのセキュリティサービスを開始
      - 2023年: 10個のセキュリティ機能を追加
  - 統一されたUI
    - 同じ操作で異なる機能が利用できる
    - セキュリティ機能もオブザーバビリティ機能も同じUI
  - 幅広いデータソース
    - 600を超えるサービスからデータを収集できる
- セキュリティ観点でいいところ3つ
  - 共通機能の活用
    - データ取得は同じものを利用している
    - 共通の機能が利用できる
    - アラートの定義やインシデント管理やダッシュボードなど
  - デフォルト機能
    - OWASPやCISといった業界標準に準拠した検知ルール・ダッシュボードをすぐに利用可能
    - セキュリティ専門知識がなくても利用可能
  - 検知・防御 + 可視化
    - 可視化されているので判断しやすい
デモ
- 5つの機能とそれに対応するピックアップ機能の紹介
- 詳しくは動画を見てね
- CSPM
  - AWSにフォーカスして、準拠状況を確認する
  - 実際にリソースをチェックして、ミュートでプルダウンから理由を選択する
- リソースカタログ
  - リソースのカテゴリで分類して俯瞰した図で見れる
  - フィルターで色々絞り込める
  - リソース単位での検知状況や、リソースに関連するものを図から見れる
- User Block
  - アプリケーションセキュリティの機能
  - 検索条件を保存する機能がある
  - 今回は本番環境の一分の内容を保存してあるので出す
  - 一人のユーザーがアタックしている事が判明
  - いろんなアクションが選べる
  - ユーザーを指定してブロックができる、期間も選択できる
- APM
  - サービス単位での脆弱性が見れる
  - Javaのアプリケーション観点で見てみる
  - サービスの中のセキュリティを見ていく
- Cloud SIEM
  - インシデントの調査
  - Roleに紐づいたアクションを確認できる
  - S3のアクションをドリルダウンでチェック

感想

いろんな観点で1つの仕組みから見れるのはいいですね。それぞれの機能が単純に機能を載せました、ではなくちゃんと実用的なことがデモからもよくわかりますね。デモを動画でみてください！

Session5:「AWSではじめるクラウドセキュリティ」の裏側を。アマゾンウェブサービスジャパン合同会社シニアセキュリティコンサルタント畠中亮さん

コチラの本の話

発行するまではドキドキしながらやっていた
いろんな評価のコメントがある
- 詳しくは上記ブログなども見てね
今回は執筆の裏側の話
執筆陣
- セキュリティアシュアランスの松本昭吾さんがきっかけ
- 畠中さん
  - プロフェッショナルサービスでクラウドセキュリティコンサルティングチームを立ち上げた
  - クラウドセキュリティ戦略の立案やセキュリティガイドラインの策定に関する支援をしている
  - 書き文字や活字、文章の読み書きが好き
  - 真面目に仕事をしている方がセキュリティの問題で足元をすくわれないようにしたい
  - 辛口の日本酒が好き
なぜこの本を書いたのか
- 企画者の想い
  - AWSを題材にセキュリティの基本を学んでもらいたい
- 畠中さんの想い
  - セキュリティを専門としていない技術者が手探りでセキュリティ対応している現状がある
  - セキュリティコンサルタントとして経験とノウハウを伝えたい
想定している読者
- 3つ
- ITの初学者
- クラウドを利用するIT技術者
- クラウドに詳しくないセキュリティ/リスク管理責任者/スタッフ
構成
- 基礎編
  - 摩擦少なく読める理念の解説
- 業務編
  - 具体的に何を実施すべきかを解説
- 実務編
  - 自分の理解の検証手順を解説
- 一番最後の「これからの学習のために」もいい内容
- 第1部: クラウドセキュリティにおける説明責任と実行責任
  - 説明責任と実行責任についての話
  - 説明責任は委任できない
- 第2部: NIST CSFを切り口としたセキュリティ業務解説
  - NISTのCSFがちょうど良さそうと議論した
  - リスクの特定とセキュリティ管理作の決定 - 設計/実装までの流れ
  - AWSの利用者が対応するのか、AWSにリスクが移転できるのかを分類
  - セキュリティ管理作を検討する
  - AWSのサービス/機能活用判断
  - 原理原則をクラウドに落としていく話
  - 本には書いてないけど応用の話
    - この考え方は企業のAWSセキュリティガイドラインに使える
  - セキュリティ管理作の要となる防御 - 最小権限
    - AWSだとIAMのアクションレベルの最小権限をやることがある
    - 開発か本番かとか、考慮しないでアクション単位の設計をしていることがある
    - そういうことではないですよ、と本では説明している
    - 粒度の使い分け
      - 開発と本番で、本番でも業務によって、どのようなデータを扱っているかによって使い分けする

感想

AWSに携わる人は全員読んでください。

Session6: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー

AWSで日本国内からのアクセスに限定したいとした場合にGeo-IP GPS(アプリ)などを利用して、AWSマネージメントサービスと組み合わせて利用する方法ってあるのでしょうか？NWファイアウォールにAPNICのJP管理アドレス帯をAcceptする設定をしてやってみるのも良いと思ったんですが、既にサービスインしている状態だと勇気が出ないな～とブルっているところなんです(あとコストも見積もれてない)

AWS WAFでGeoIPを使った国選択ができるので、それを使うのが一番簡単そう

フォレンジック基盤って、みんな用意してる？何使ってる？（AWSならDetective,SIEM on ES or PaaS？）何を決めてにして、それを選んだの？

何をやりたいか次第ではある
メモリのフォレンジックもやりたければそういうツールの導入とかも必要

開発、保守用で必要な開発者のアカウント管理を皆様どうやっておられますか？社内に親Organizationがあり、その子アカウントとしてサービス開発をしており、以下の課題があり困っています。

課題1: ユーザ管理、社内メンバと社外メンバーを同一に管理するか、分けて管理するべきか？実際どうやっているか？
- まず全社のID戦略を決めてもらったほうがいい
- その上で全体のものに乗せるのかの戦略を決めるべき
- 例えばAzure ADで従業員のものを統一し、プロジェクト単位のものはAWS IAM Identity Centerに個別に乗せるなどはある
課題2: 開発ツールを使う上で、Saasそのものの認証のままだと2要素認証が無いために認証強化をして使いたい。各開発チームごとにAWS SSO使ってSAML連携、などをやるモノでしょうか？
- 2要素認証ができないなら使わない